Jenkins Builds

@qfrank, this is amazing, thanks a lot!

Do you notice any performance difference when using status as a server?

I tried the PR, and it seems to work, but because status-go is still compiled for mobile, it's hard for me to tell if everything is working or if something is falling back to the "normal" status-go.

In other words, changes in status-go code still cause a full rebuild even when STATUS_BACKEND_ENABLED is 1 whenever make run-android runs (I simulated this by setting STATUS_GO_SRC_OVERRIDE, but it would be the same if switching branches when the revision in status-go-version.json is different). Are you planning on fixing this in a follow-up PR?

Not quite.
I had considered whether we could compile status-mobile without relying on status-go. Perhaps we can use some means to achieve this purpose, but I need to discuss it with Sid. However, I think the priority of this requirement is low because with the help of this PR, in most cases, we only need to compile status-mobile once (except for modifying or adding native implementations with Kotlin or Objective-C). If STATUS_BACKEND_ENABLED(EDIT: renamed to STATUS_BACKEND_SERVER_ENABLED now) is 1, STATUS_GO_SRC_OVERRIDE or status-go-version.json should have no impact as all invocation from native-module.core will delegate to status backend server you're running, so it actually depends on what version of status-go you're running for status backend server.

Also, status-backend is running correctly, but I don't see any logs in its STDOUT, only in the make run-android output. Is it because of what you said in the description? Update the Android log store location.

I'm sorry to hear this ... Because the status backend server is not mature enough. We can improve it later in separate PR. If you want see something output from STDOUT, you can change level to DEBUG, you can add fmt.Println here to see what signal sent to frontend. you can change here to see any new websocket connected. change here and here to see what request reached out from frontend.
Additionally, there should exist requests.log and geth.log in directory <path>/status-go/root-data in your case with latest commit. But rootDataDir value(/status-go/root-data) you provided seems strange, it should be an absolute path

As a suggestion, apart from the PR instructions, it would be great to have documentation in the source about how to use the status-backend. Another point worth mentioning in docs is that the developer should make sure the status-backend is checked out to a revision that's at least compatible with the revision in status-mobile/status-go-version.json.

Sounds great, I'll add it later @ilmotta

@qfrank, this is amazing, thanks a lot!

Do you notice any performance difference when using status as a server?

not yet, WDYT of this performance regarding invocation log from requests.log, pls notice the duration:

2024-11-05T12:32:37.938+0800	DEBUG	RequestLogger	call	{"method": "callPrivateRPC", "params": "[{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"wakuext_contacts\",\"params\":[]}]", "resp": "{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":null}", "duration": "152.209µs"}
2024-11-05T14:11:43.752+0800	DEBUG	RequestLogger	call	{"method": "appStateChangeV2", "params": "[{\"state\":\"active\"}]", "resp": "{\"error\":\"\"}", "duration": "612.625µs"}

I think it's okay for most cases. If we have special requirements, maybe we can invoke specific native functions that pretty stable through embed statusgo or try other optimization solution, this is another feature we can do

I had considered whether we could compile status-mobile without relying on status-go. Perhaps we can use some means to achieve this purpose, but I need to discuss it with Sid.

Thanks @qfrank. No worries, let's leave at that and we can improve in the future. One day we may get there!

It would be nice if we could get logs in the status-backend process output

Currently, it goes into geth.log as initLogging works. You can use tail -f geth.log to see the output. I can create a separate PR to make the log message output to stdout as well when we use the status backend server after this PR is merged.